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Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (1999). All Rights Reserved. 
Abstract 
This document describes extensions to "Simple Mode of Facsimile Using 
Internet Mail" [RFC2305] and describes additional features, including 


transmission of enhanced document characteristics (higher resolution, 
color) and confirmation of delivery and processing. 


These additional features are designed to provide the highest level 
of interoperability with the existing and future standards-compliant 
email infrastructure and mail user agents, while providing a level of 
service that approximates the level currently enjoyed by fax users. 


The IETF has been notified of intellectual property rights claimed in 
regard to some or all of the specification contained in this 
document. For more information consult the online list of claimed 
rights in <http://www.ietf.org/ipr.html>. 


1. Introduction 
This document notes a number of enhancements to the "Simple Mode of 


Facsimile Using Internet Mail" [RFC2305] that may be combined to 
create an extended mode of facsimile using Internet mail. 


The new features are designed to be interoperable with the existing 
base of mail transfer agents (MTAs) and mail user agents (MUAS), and 
take advantage of existing standards for advanced functionality such 
as positive delivery confirmation and disposition notification. The 
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enhancements described in this document utilize the messaging 
infrastructure, where possible, instead of creating fax-specific 
features which are unlikely to be implemented in non-fax messaging 
software. 


This document standardizes the following two features. 


Delivery confirmation (Section 2) (required) 
* Additional document features (Section 3) (optional) 


These features are fully described in another document titled 
"Terminology and Goals for Internet Fax" [RFC2542]. 


1.1. Definition of Terms 
The term "processing" indicates the action of rendering or 
transmitting the contents of the message to a printer, display 


device, or fax machine. 


The term "processing confirmation" is an indication by the recipient 
of a message that it is able to process the contents of that message. 


The term "recipient" indicates the device which performs the 
processing function. For example, a recipient could be implemented 
as a traditional Mail User Agent on a PC, a standalone device which 
retrieves mail using POP3 or IMAP, an SMTP server which prints 
incoming messages (similar to an LPR server). 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.2. GSTN Fax Gateways ("onramp"/"offramp") 


The behavior of gateways from GSTN fax to SMTP ("onramps") and from 
SMTP to GSTN fax ("offramps") are not described in this document. 
However, such gateways SHOULD have the behavior characteristics of 
senders and recipients as described in this document. 


2. Delivery and Processing Confirmation 


In traditional GSTN-based realtime facsimile, the receiving terminal 
acknowledges successful receipt and processing of every page [T.30]. 


In Internet Mail, the operations of Delivery (to the mailbox) and 
Disposition (to paper or a screen) may be separated in time (due to 
store and forwarding of messages) and location (due to separation of 
delivery agent (MTA) and user agent (MUA)). The confirmation of 
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these two operations are supplied by two different standards-track 
mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] 
and Message Disposition Notifications (MDN) [RFC2298], respectively. 


This section defines requirements for devices or services that are to 
be considered compliant with this document. 


2.1. Sender Requirements 


Because delivery failure may occur (over disk quota, user no longer 
exists, malconfigured mailer), a delivery failure message (in the 
format described by [RFC1894] or otherwise) may be sent to the 
envelope-from address specified by the sender. Thus, the envelope- 
from address supplied by the sender MUST be able to properly handle 
such delivery failure messages. 


2.1.1. Delivery Confirmation 


If the sender desires delivery confirmation, the sender MUST request 
Delivery Status Notification by including the the esmtp-keyword 
NOTIFY with the esmtp-value SUCCESS (section 5.1 of [RFC1891]). 


2.1.2. Processing Confirmation 


If the sender desires processing confirmation, the sender MUST 
request Message Disposition Notification ([RFC2298] section 2) when 
sending the message itself. 


Because a recipient may silently ignore a request for an MDN (section 
2.1 of [RFC2298]) at any time: 


* MDNs MUST NOT be used for delivery confirmation, but are only 
useful for disposition ("processing") notification. 


* the sender MUST NOT assume the recipient will respond to an MDN 
request in a subsequent message, even if the recipient has done 
so in the past. 


The address provided by the sender on the Disposition-Notification-To 
field MUST be able to receive Message Disposition Notifications 
messages [RFC2298] and SHOULD be able to receive messages that are 
not in the Message Disposition Notification format (due to the 
existence of legacy systems that generate non-RFC2298-compliant 
responses to the Disposition-Notification-To field). The 
Disposition-Notification-To address and the envelope-from address 
SHOULD match to allow automated responses to MDN requests (section 
2.1 of [RFC2298]). 
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Dees; Recipient Requirements 


Recipients SHOULD implement Message Disposition Notifications 
[RFC2298] and SHOULD indicate supported media features in DSN and MDN 
messages per [RFC2530]. 


If the recipient is an SMTP server, it behaves as part of the 
receiver infrastructure and is therefore subject to the "Receiver 
Infrastructure" requirements of this document. 


See also "Recipient Recommendations" in section 5. 
2.2.1. MDN Recipient Requirements 


Recipients MUST be configurable to silently ignore a request for an 
MDN (section 2.1 of [RFC2298]). 


If the recipient is an automated message processing system which is 
not associated with a person, the device MAY be configurable to 
always respond to MDN requests, but in all cases MUST be configurable 
to never generate MDNs. 


A recipient MUST NOT generate an unsolicited MDN to indicate 
successful processing. A recipient MAY generate an unsolicited MDN 
(sent to the envelope-from (Return-Path:) address) to indicate 
processing failure, but subject to the [RFC2298] requirement that it 
MUST always be possible for an operator to disable unsolicited MDN 
generation. 


2.2.2. Recipients Using Mailbox Access Protocols 


A recipient using POP3 [RFC1939] or IMAP4 [RFC2060] to retrieve its 
mail MUST NOT generate a Delivery Status Notification message 
[RFC1894] because such a notification, if it was requested, would 
have already been issued by the MTA on delivery to the POP3 or IMAP4 
message store. 


The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields, 
"Boc:" fields, or any other fields containing header recipient 
information to determine the ultimate destination mailbox or 
addressee, and SHOULD NOT use other RFC822 or MIME fields for making 
such determinations. 
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2.3. Messaging Infrastructure Requirements 


This section explains the requirements of the SMTP messaging 
infrastructure used by the sender and receiver. This infrastructure 
is commonly provided by the ISP or a company’s internal mailers but 
can actually be provided by another organization with appropriate 
service contracts. 


2.3.1. Sender Infrastructure 


Support for DSN [RFC1891] MUST be provided by the mail submission 
server [RFC2476] used by the sender and MUST be provided up to the 
mailer responsible for communicating with external (Internet) 
mailers. 


Also see section 5.1 of this document. 
2.3.2. Receiver Infrastructure 


Support for DSN [RFC1891] MUST be provided by the external 
(Internet-accessible) mailer, and MUST be provided by each mailer 
between the external mailer and the recipient. If the recipient is 
implemented as an SMTP server it MUST also support DSN [RFC1891]. 


3. Additional Document Capabilities 


Section 4 of "A Simple Mode of Facsimile Using Internet Mail" 
[RFC2305] allows sending only the minimum subset of TIFF for 
Facsimile "unless the sender has prior knowledge of other TIFF fields 
or values supported by the recipient." 


A recipient MAY support any or all (or any combination) of the TIFF 
profiles defined in RFC 2301, in addition to profile S. A recipient 
which supports additional profiles SHOULD indicate this support as 
per section 3.2 or 3.3 of this document. As a consequence, a sender 
MAY use those additional TIFF profiles when sending to a recipient 
with the corresponding capabilities. 


A sender SHOULD be able to recognize and process the feature tags as 
defined in [RFC2531] when reviewing the capabilities presented by a 
potential recipient. The capability matching rules indicated there 
(by reference to [RFC2533]) allow for the introduction of new 
features that may be unrecognized by older implementations. 


A sender MAY send a message containing both the minimum subset of 


TIFF for Facsimile (as specified in [RFC2305]) and a higher quality 
TIFF using multipart/alternative. 
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Three methods for the sender to acquire such knowledge are described: 


1. Sender manual configuration 
2. Capabilities in Directory 
3. Capabilities returned in MDN or DSN 


Method (3) SHOULD be used. 


An implementation may cache capabilities locally and lose 
synchronization with the recipient’s actual capabilities. A 
mechanism SHOULD be provided to allow the sender to override the 
locally-stored cache of capabilities. Also note section 4.1 of this 
document. 


3.1. Sender Manual Configuration 
One way a sender can send a document which exceeds the minimum subset 


allowed by [RFC2305] is for the user controlling the sender to 
manually override the default settings, usually on a per-recipient 


basis. For example, during transmission a user could indicate the 
recipient is capable of receiving high resolution images or color 
images. 


While awkward and not automatic, this mechanism reflects the current 
state of deployment of configuration for extended capabilities to 
ordinary Internet email users. 


3.2. Capabilities in Directory 


A future direction for enhanced document features is to create a 
directory structure of recipient capabilities, deployed, for example, 
through LDAP or DNS. The directory would provide a mechanism by which 
a sender could determine a recipient’s capabilities before message 
construction or transmission, using a directory lookup. Such 
mechanisms are not defined in this document. 


There is active investigation within the IETF to develop a solution 
to this problem, which would resolve a wide range of issues with 
store-and-forward messaging. 


3.3. Capabilities Returned in MDN or DSN 


As outlined in section 2 of this document, a sender may request a 
positive DSN or an MDN. 
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If the recipient implements [RFC2530], the DSN or MDN that is 
returned can contain information describing the recipient’s 
capabilities. The sender can use this information for subsequent 
communications with that recipient. 


The advantage of this approach is that additional infrastructure is 
not required (unlike section 3.2), and the information is acquired 
automatically (unlike section 3.1). 


3.3.1. Restrictions and Recommendations 


A sender MUST NOT send a message with no processable content to 
attempt to elicit an MDN/DSN capability response. Doing so with a 
message with no processable content (such as a message containing 
only a request for capabilities or a blank message) will confuse a 
recipient not already designed to understand the semantics of such a 
message. 


A recipient SHOULD indicate the profiles and features supported, even 
if the recipient supports only Tiff Profile S (the minimum set for 
fax as defined by [RFC2305]) [RFC2531]. This allows a sender to 
determine that the recipient is compliant with this Extended 
Facsimile Using Internet Mail specification. 


4. Security Considerations 


As this document is an extension of [RFC2305], the Security 
Considerations section of [RFC2305] applies to this document. 


The following additional security considerations are introduced by 
the new features described in this document. 


4.1. Inaccurate Capabilities Information 


Inaccurate capability information (section 3) could cause a denial of 
service. The capability information could be inaccurate due to many 
reasons, including compromised or improperly configured directory 
server, improper manual configuration of sender, compromised DNS, or 
spoofed MDN. If a sender is using cached capability information, 
there SHOULD be a mechanism to allow the cached information to be 
ignored or overridden if necessary. 


4.2. Forged MDNs or DSNs 


Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] can 
provide incorrect information to a sender. 
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5. Implementation Notes 
This section contains notes to implementors. 
5.1. Submit Mailer Does Not Support DSN 


In some installations the generally available submit server may not 
support DSNs. In such circumstances, it may be useful for the sender 
to implement [RFC974] mail routing as well as additional submission 
server functions [RFC2476] so that the installation is not 
constrained by limitations of the incumbent submission server. 


5.2. Recipient Recommendations 


To provide a high degree of reliability, it is desirable for the 
sender to know that a recipient could not process a message. The 
inability to successfully process a message may be detectable by the 
recipient’s MTA or MUA. 


If the recipient’s MTA determines the message cannot be processed, 
the recipient’s MTA is strongly encouraged to reject the message with 
a [RFC1893] status code of 5.6.1. This status code may be returned 
in response to the end-of-mail-data indicator if the MTA supports 
reporting of enhanced error codes [RFC2034], or after message 
reception by generating a delivery failure DSN ("bounce"). 


Note: Providing this functionality in the MTA, via either of the 
two mechanisms described above, is superior to providing the 
function using MDNs because MDNs must generally be requested 
by the sender (and the request may, at any time, be ignored by 
the receiver). Message rejection performed by the MTA can 
always occur without the sender requesting such behavior and 
without the receiver circumventing the behavior. 


If the message contains an MDN request and the recipient’s MUA 
determines the message cannot be processed, the recipient’s MUA is 
strongly encouraged to repond to an MDN request and indicate that 
processing failed with the disposition-type "processed" or 
"displayed" and disposition-modifier "error" or "warning" [RFC2298]. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Masinter & Wing Standards Track [Page 12] 


